終於可以把物件導向的概念完成囉！
就使用SOLID作為到目前為止的總結吧！

S

Single Responsibility Principle 在第三天的時候其實就有詳細介紹單一職責的概念了，從顯而易見的類別開始，再到內部行為的方法，都說明了SRP的重要！
但除了易讀性以外，在現實面裡還要考慮到類別是否過於龐大，或者一個方法內的數據結構，造成不易修改的狀況
這時重構就有了必要，將各個切割成更小的部分，而最重要的依據就是行為責任
我以Robert的概念為基準，來舉一個例子－金流串接
當我們串接金流時，若是定義一個方法內完成所有步驟時，該怎麼設計才好？
在沒有單一職責概念時，會許會將所以加密與發送請求等步驟完全裸露在同一個方法內
那今天要修改的話就無所依據，不知道哪一個過程發生問題...
但若是將每一個步驟封裝起來，例如加密就單純作加密的動作，這樣若是加密出錯了，也可以立刻發現問題

O

Open/Closed Principle 這個原則也是必要的元素－開閉原則

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

這概念需要使用到依賴注入（Dependency Injection），或者使用 繼承（Inheritance） 所達成，當我們新增一個類別時，使用 鴨子型別（Duck typing） 免去修改介面內的邏輯，或者在新增介面使用繼承將方法覆蓋父類別，這些水平或者垂直的設計方法，都可以完成開閉原則（Open/Closed Principle）

L

Liskov Substitution Principle －里氏替換原則

If S is a subtype of T, then objects of type T may be replaced with objects of type S

從定義看出～ 這是數學...
但在Ruby內的含義，並沒有很難～
首先這裡的Type指的是指資料型態，如果一個繼承結構內，覆蓋了父類別內的方法時，子類別回傳型態也要與父類別一致
舉例來說，哺乳內被人類與貓類繼承，若是哺乳類的聲音方法回傳的資料型態為聲波，那麼人類跟貓類複寫的聲音方法，也要是聲波，不可以是光波或者地震波...

I

Interface segregation principle －介面隔離原則

Pass no more than four parameters into a method. Hash options are parameters.

還記得Day 4所分享的嗎！？
我們知道每次使用介面（方法）時，並非每個參數都需要使用到
若是照著介面參數依序被迫輸入內容時，代表依賴關係需要重構才行
因此使用Hash與預設值，來讓介面更加彈性與實用

D

Dependency Inversion Principle －依賴反轉原則

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

同樣在Day 4時分享的內容，其實整個反轉的最主要原因，都是要依賴抽象會更為安全可靠
因為抽象內容是多型的實踐，可以不用限定參數來實施方法

接下來的模式都會圍繞著這些概念去設計，所以請用SOLID去體會設計模式內每一個類別與介面設計，這些結構都是要完成物件導向的核心概念SOLID！

很開心明天開始就可以討論設計模式囉～ 一起加油吧 ：）

感謝大家 如有問題，再煩請大家指教！